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A 

TECHNICAL  BRIEFING 
on 

THE  INITIAL  GRAPHICS  EXCHANGE  SPECIFICATION  (IGES) 


Introduction 


This  technical  briefing  is  composed  of  two  parts.  Part  1 
consists  of  a set  of  slides*  and  some  associated  text.  The 
slides  and  the  text  are  organized  in  tandem.  The  intent  of  the 
text  is  to  furnish  associated  information  (for  each  slide)  as  op- 
posed to  furnishing  specific  text  that  is  to  be  read  verbatim. 
The  information  in  this  section  is  ‘'soft*'*  that  is*  not  overly 
technnical.  In  this  Part  the  suggested  slides  for  each  section 
follow  the  first  page  of  the  text  of  the  section. 


Part  2 consists  of  the  more  technical  material.  Here  the 
intent  is  to  furnish  text  that  can  be  read  verbatim  for  each 
slide.  In  this  Part  the  suggested  text  follows  each  slide. 


There  is  minimal  overlap  between  the  two  sections. 
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I.  Introduction  To  IGES 


1. 1 Overview 
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IGES  represents  an  initial*  organized  attempt  to  address 
and  resolve  the  interface  problems  that  arise  as  a result  of  the 
introduction  of  the  computer  into  the  design  and  manufacturing 
environment.  The  interface  problems  may  have  their  origins  in 
either  hardware  or  software*  and*  roughly  speaking*  can  be 
character i zed  by  the  fact  that  the  data  as  produced  by  one 
system  (or  subsystem)  is  not  able  to  be  used  by  another  system 
(or  subsystem).  It  is  the  common  experience  of  many  users  that 
the  resolution  of  the  interface  problems  associated  with  the 
creating*  transmi tt ing*  storing*  and  retrieving  of 
computer-generated  data  is  necessary  in  order  that  the  full 
potential  of  the  computer  for  increased  productivity  be 
rea 1 i z ed. 


Several  large  companies  have  expended  significant  resources 
in  individual  attempts  to  resolve  their  own  internal  interface 
problems.  Thus*  translators  have  been  written  so  that  data  can 
be  communicated  from  system  to  system.  Subsequently*  some 
companies  felt  the  need  to  devise  standard  data  structures  and 
formats  in  order  to  curtail  the  resulting  proliferation  of 
translators.  It  is  also  the  common  experience  of  these 
companies  that  the  translators  were  expensive  to  develop* 
expensive  to  maintain*  and  achieved  only  limited  efficiency. 


These  individual  attempts  at  resolving  interface  problems 
have  emphasized  the  lack  of  any  appropriate  standardized 
specification  for  a communication  format  for  data  exchange*  and 
they  have  also  emphasized  the  need  for  some  such  specification. 
Furthermore*  with  the  increasing  variety  of  vendors*  and  the 
present  acquisition  rate  of  CAD/CAM  systems  by  both  government 
and  private  organizations,  the  need  will  continue 
IGES  is  an  attempt  to  address  this  need, 
an  organized  effort  on  a national  level  to 
specifications  where  none  presently  exists 
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' IGES 

A Project 
of  the 
Air  Force 
ICAiVi  Program 


Funding  Provided  By  Air  Force,  Army, 
Navy,  and  NASA.  Coordinated  Through 
ICAM  Office 


Contract  To  National  Bureau  of 
Standards  For  Direction  and  Coordination 
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Interface  Areas: 

1.  Between  Different  Interactive  Graphics 
Design-Drafting  Systems 

— Different  Suppliers 
— Same  Supplier,  Different  Versions 

2.  Between  Interactive  Graphics  Design- 
Drafting  Systems  + Externa!  Applica- 
tions Programs 

3.  Between  Interactive  Graphics  Design- 
Drafting  Systems  and  Archival  Storage 


The  EGES  Goal: 

Resolve  The  Interface  Problems 

To  Provide 

1.  Increased  Productivity 

2.  Increased  Flexibility 


Heretofore  — 

Isolated,  Individual  Company 
Attempts  To 

Resolve  Interface  Problems 


1.  Write  processors  (translators) 

2.  Develop  local  standards 


Shortfalls  Of  Isolated  Attempts 
— Company  Viewpoint 

1.  Expensive  to  Develop 

2.  Expensive  to  Maintain 

3.  Limited  Efficiency 
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Shortfalls  Of  Isolated  Attempts 

1.  Duplication  Of  Effort 

2.  isolation  Still  Exists  — 

Now  On  Company  Level 

3.  Lack  Of  Forum  For 
Convergence  Of  Ideas 


SGES  Provides 

1.  An  Initial  Framework 
Where  None  Presently  Exists 

2.  An  Organized  Attempt 
On  A IMaiional  Level 

3.  A Forum  For  Convergence 
Of  Ideas 
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IGES  Accomplishments 

1.  Produced  A Set  of  Specifications 

2.  Embarked  On  A Schedule  For 
Testing,  Benchmarking,  Imple- 
mentation 

3.  Initiated  Efforts  Toward  Becoming 
An  American  National  Standard 

4.  Filled  Over  1000  Requests  For  The 
Set  Of  Specifications 


IGES 

Is  Rapidly  Becoming 
Accepted  As  A 
DeFacto  Standard 


Basis  Of  User  Interest  In  IGES 

1.  Resolve  interface  problems 
associated  with  creating,  trans- 
mitting, using,  and  storing  of 
computer-generated  product  defi- 
nition data 

2.  Provide  insulation  from  supplier 
revisions 


Indications  Of  User  Commitment 
To  IGES 

1.  Number  and  variety  of  organizations  on 
IGES  committees 

2.  Many  written  declarations  of  support  for 
development  and  success  of  IGES 

3.  Users  are  beginning  to  specify  IGES  com- 
pliance in  procurement  specifications 
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Companies  Having  a Representative 
on 

At  Least  One  IGES  Committee 


Advanced  Technology,  Inc. 

Applicon 

Auto-trol 

Aydin  Controls 

Bechtel 

Bendix 

Boeing 

CALMA 

CAM-1 

Combustion  Engineering,  Inc. 

Computervision 

Control  Data 

DMT  Corporation 

DuPont 

Evans  and  Sutherland 
Ford 

General  Dynamics 
General  Electric 
General  Motors 
Gerber 

Harry  Diamond  Labs 
Holquin  and  Assoc. 

Hughes 


IBM 

International  Harvester 
John  Deere 

Manufacturing  Data  Systems,  Inc. 
Martin  Marietta 

McDonnell  Douglas  Automation  Co. 
NASA 

National  Bureau  of  Standards 
National  Computer  Systems 
Ocean  Data  Systems 
Racal  Redac 
Rockwell  International 
Sandia  Labs 

Society  of  Manufacturing  Engineers 

Structural  Dynamics  Research  Corp. 

Time  Engineering 

Union  Carbide 

U.S.  Air  Force 

U.S.  Army 

U.S.  Navy 

Vought 

Westinghouse 

Xerox 
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Basis  of  Supplier  Interest 

In  IGES 

1.  IGES  provides  a recognized, 
common  receptacle  for  getting 
data  out  of  their  own  system 

2.  It  is  good  business— customers 
w&nt  the  IGES  type  capability 


Indications  Of  Supplier 
Commitment  To  IGES 

1.  Written  and  oral  declarations  of 
commitment  at  the  managerial 
level  from  several  suppliers 

2.  Detailed  technical  design 
meetings  scheduled  between 
IGES  and  participating  suppliers 
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An  IGES  Self-Assessment 

. . IGES  is  not  perfect,  it  will  not 
solve  all  the  information  needs  of 
CAD/CAM  systems,  and  it  will  need 
further  extension  beyond  its  current 
definition.  However,  IGES  goes  a long 
way  toward  alleviating  the  current  data 
exchange  problems,  and  is  a signifi- 
cant response  to  today's  needs." 
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The  IGES  effort  has  thus  far  produced  a published  set  of 
specifications  tuithin  the  time  frame  which  was  originally  laid 
down#  and  it  has  embarked  on  an  implementation#  testing#  and 
benchmarking  schedule.  [See  Reference  81  It  has  attracted 
national  attention.  CSee  Reference  101  The  IGES  mailing  list 
now  contains  over  one  thousand  names.  There  is  currently 
underway  an  effort  having  to  do  with  IGES  becoming  an  American 
National  Standard.  In  actual  fact#  it  is  rapidly  becoming  a de 
facto  national  standard ! 

It  is  important  that  both  users  and  suppliers  of  CAD/CAM 
systems  have  a legitimate  basis  of  interest  in  the  development 
and  ultimate  success  of  IGES.  It  is  also  important  that  both 
users  and  suppliers  make  commitments  to  the  development  of  IGES. 
At  the  present  time#  there  is  ‘ evidence  that  such  commitments 
have  been  made. 

It  is  also  important  to  note  that  IGES  is  not  being  billed 
by  itself  or  by  anyone  else  as  the  answer  to  all  database 
exchange  problems  that  currently  exist.  Hopefully#  IGES  will 
succeed  on  the  basis  of  its  demonstrated  merits#  or  fail  for 
lack  of  same.  The  following  self-assessment  statement  concludes 
the  Introduction  of  the  IGES  report:  "In  summary#  IGES  is  not 
perfect#  it  will  not  solve  all  the  information  needs  of  CAD/CAM 
systems#  and  it  will  need  further  extension  beyond  its  current 
definition.  However#  IGES  goes  a long  way  toward  alleviating 
the  current  data  exchange  problems#  and  is  a significant 
response  to  today's  needs." 


1.  2 A typical  scenario  of  development  of  user  need  for  IGES 

Historically,  the  interface  problems  have  become  apparent  - and 
acute  - in  parallel  with  the  introduction  of  commercially 
available  interactive  graphics  design-drafting  systems. 
Interface  problems  associated  with  these  systems  have  continued 
unabated  to  the  present  day#  and  these  systems  constitute  the 
focal  point  of  the  IGES  effort. 

For  example#  the  first  acquisition  for  many  companies  was 
the  procurement  of  an  interactive  graphics  drafting  system. 
This  self-contained  system  brought  about  significant  improvement 
over  manual  drafting.  The  next  acquisition  was  usually  the 
addition  of  a high  speed  plotter#  possibly  from  a different 
supplier.  This  acquisition  brought  about  further  improvements 
in  productivity#  but  it  also  brought  about  a new  concern  - the 
interface  compatibility  of  the  two  systems.  Further  procurement 
of  new  generation  drafting  systems#  again  possibly  from 
different  suppliers#  gave  extended  capability  but  also 
additional  compatibility  problems. 

Increased  sophistication  of  the  commercially  available 
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A Typical  Scenario 
. Of  Development 
Of  User  Need  • 
For 
IGES 
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For  Bidirectional  Communication 
Between  N Centrally 
Connected  Systems 

1-  2N  Interfaces  Will  Suffice" 

2.  An  Additional  System 

Necessitates  Only  2 New  Interfaces 


A Summary  Of  Typical  Interface 
Problems  involving  Interactive 
Graphics  Design-Drafting  Systems 

1.  Hardcopy-postprocessing— COM,  plotters,  etc. 

2.  Mainframe-based  applications— Mass  Properties, 
other  Involved  Analyses 

3.  Other  Design-Drafting  Systems— Cross- 
Translation 

4.  Mainframe  Storage 

5.  Manufacturing  data— NC  data,  routing  data 
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sy stems 
process# 
interf ac 
systems# 
systems. 


brought  about  an  evolution  of  their  role  in  the  design 
and  with  that  came  more  interface  ' problems: 
ing  internal  applicationa-specif ic  software  to  these 
now  aptly  described  as  general  purpose  design-drafting 


Orowth  in  the  size  of  the  company  user  base  for  these 
systems  resulted  in  further  interface  problems#  as  other 
divisions  made  their  procurements.  Increased  user 
sophistication  resulted  in  the  formation  of  large  central 
databases#  and  this  led  to  still  another  interface  area  - the 
interface  between  a commercial  system  and  the  database. 
Reflected  here  was  a basic  change  in  the  user  view  of  these 
systems.  Instead  of  being  viewed  strictly  as  a self-contained 
unit#  they  could  be  given  the  added  role  of  an  interactive 
communication  tool  between  a user  and  a database. 
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1. 3 Cross- translation#  the  focal  point  of  XGES 


The  competitiveness  and  the 
world  in  which  we  live  accounts 
effort.  This  is  cross-transla 
between  interactive  graphics 
different  brand  name.  From  the  c 
user#  progress  in  this  interfac 
to  be  made.  From  the  competitive 
progress  in  this  area  would  open 

This  interface  area  is  the 
certainly#  this  is  the  one 
barometer  for  the  success 
expectation  - is  that  IGES  b 
of  the  structure  of  the  databa 
being  able  to  accommodate  only 
pen  position  information.  In 
type  of  information  was  decl 
be  inadequate  because  it  did  n 
The  motivitation  behind  str 
structure  as  possible  is  that# 
should  be  usable  on  a par  with 


diversity  that  exist  in  the 
for  the  focal  point  of  the  IGES 
tion*  or#  database  exchange 
design-draf ting  systems  of 
ompetitive  point  of  view  of  the 
e area  would  allow  the  best  buy 
point  of  view  of  the  supplier# 
potential  new  markets. 

most  demanding  one.  Almost 
which  will  serve  as  the  primary 
of  IGES.  The  need  - and  the 
e able  to  accommodate  th»  exchange 
ses  in  question#  as  opposed  to 
the  exchange  of  the  equivalent  of 
fact#  the  exchange  of  this  latter 
ared  at  the  very  outset  of  IGES  to 
ot  constitute  database  exchange, 
iving  for  the  exchange  of  as  much 
following  an  exchange#  the  data 
what  it  was  when  it  was  created. 


IGES  pre-  and  post-processors  comprise  the  ingredients  for 
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IGES  Contents 

Entities— The  Basic  IGES 

Units  of  Information 

1.  Geometry  Entities 

2.  Annotation  Entities 

3.  Structure  Entities 
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Cross-Translation 

Between  Interactive  Graphics  Design-Drafting  Systems 


(Entities) 


Pre 


Entities 


Post 


■>-{  Entities) 


SGES  Design  Goafs  for  the 

Cross-T  ranslation  Application 

1.  Basic  database  information, 
including  complex  structures  and 
relationships,  be  exchanged. 

2.  Following  exchange,  the  data 
should  be  usable  on  a par  with 
what  it  was  when  it  was  created 
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Basis  of  User  Interest  In 
Cross-Translation 

1.  User  presently  owns  more  than 
one  type  of  system 

2.  User  wishes  more  supplier  in- 
dependence in  the  future 

3.  User  wishes  to  accommodate 
his  customers  by  providing  data 
in  the  form  they  wish  to  see  it. 


Basis  of  Supplier  Attitudes 
Toward  Cross-Translation 

1.  Pro— Opens  Up  Potential  New 
Markets 

2.  Con— Tends  to  Decrease 
Individuality 
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The  IGES  Role  in  Cross-Translation 

1.  Consider,  react,  advise,  concerning  entity 
associations  specified  by  suppliers 

2.  Provide  forum  between  users  and 
suppliers 

3.  Facilitate  future  demonstration  of  capabi- 
lity in  this  area 
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the  cross-tranalat ion  application.  In  the  IGES  scheme#  each 
partic ipating  supplier  of  an  interactive  graphics 
desi gn-draf t ing  system  will  implement  processors  between  his  own 
system  and  the  communication  file.  Thus  supplier  commitment  and 
involvement  are  crucial  to  the  IGES  effort. 


A pre-processor  is  a software  module  designe 
information  structured  according  to  a specific 
translate  it  into  the  communication  file 
post-proc essor  accepts  information  structured  acc 
communication  file  format#  and  translates  it  into 
system  format.  For  example#  in  transferring  inf 
system  A to  system  B#  the  pre-processor  lies  betwe 
and  the  communication  file#  and  the  post-processor 
the  communication  file  and  system  B. 
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format.  A 
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The  first  generation  of  IGES  processors  will  rely  on  fixed# 
predetermined  entity  associations  in  both  the  pre-  and  the 
post-processors. 


The  general  role  that  IGES  will  play  in  thi 
that  of  coordinator  between  users  and  suppliers, 
to  involve  itself  in  discussions  in  an  effor 
react#  and  advise  concerning  the  entity  associ 
by  suppliers.  IGES  will  try  to  promote  understa 
seek  to  develop  concensus#  but  will  not  be 
legalisms#  or  in  certification  situations  su 
whether  or  not  a given  supplier  "meets"  IGES. 
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1.4  Preset  goals  for  the  IGES  Specif ications* 


Work  toward  producing  the  present  set  of  IGES 
specif ications  began  on  October  11#  1979.  On  that  day#  the  IGES 
Technical  Committee  was  formed#  and  commissioned  to  produce  a 
set  of  specifications.  This  Committee  was  chaired  by  Dr.  Roger 
Nagel  of  the  National  Bureau  of  Standards#  and  contained  as 
members  Walt  Braithwaite  of  Boeing#  and  Dr.  Phillip  Kennicott 
of  General  Electric.  Because  of  the  immediacy  of  the  need#  the 
driving  force  of  this  Committee  was  to  publish  a set  of 
specifications  by  early  1980.  Three  months  of  intensive  effort 
resulted  in  the  presently  available  set  of  specifications  being 
put  in  the  mail  in  late  January. 


Other  goals  influenced  the  IGES  development.  These  were 

1.  Completeness  - The  format  had  to  allow  communication  of 

* As  evidence  of  the  fact  that  acronyms  do  indeed  assume  a 
life  of  their  own  after  a while#  the  phrase  "IGES 
Specifications"  will  continue  to  be  used  in  spite  of  the 
redundancy  involved. 
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Preset  Goals  for  the 
IGES  Specifications 

The  Overriding  goal  — Published 
Early  1S80 

Others 

1.  Completeness 

2.  Extensibility 

3.  Processor 
Compatability 

4.  Responsive  to 
Community  Input 


IGES  Technical  Committee 

1.  Roger  Nagel,  Ph.D., 

National  Bureau  of  Standards 

2.  Walt  Braithwaite,  M.S., 

Boeing  Commercial  Airplane  Co. 

3.  Philip  Kennicott,  Ph.D., 

General  Electric  Co. 
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basic  geometrical*  annotation*  and  structural  entities 
(an  entity  is  the  basic  unit  of  information  in  IGES.  ) 

2.  Extensibility  - The  format  had  to  allow  the 
communication  of  material  defined  after  IGES  was 
published. 

3.  Processor  compatibility  - The  format  was  not  to  demand 

a quantum  jump  in  the  state  of  the  pre-  and 

post-processor  art. 

4.  The  format  was  to  be  based  on  as  much  input  as  possible 
from  the  interested  community. 


1. 5 Brief  history*  present  committee  structure  of  IGES 


The  idea  to  create  a graphics  exchange  specification  as  an 
immediate  step  in  the  solution  of  the  data  exchange  problem 
first  surfaced  at  the  DOD/MTAG*  meeting  in  Detroit  in  September* 
1979.  The  CAD/CAM  workshop  at  that  meeting  recommended  that  a 
meeting  be  held  within  thirty  days  to  formulate  a set  of 
exchange  spec  if ications  for  publication  early  in  1980.  As  a 
result  of  that  recommendation*  a meeting  was  convened  by  the  Air 
Force*  Army*  Navy*  NASA*  and  NBS  at  the  National  Academy  of 
Sciences  on  October  11*  1979. 


The  October  11  meeting  was  used  as  a forum  for  a discussion 
of  the  IGES  concept.  Presentations  were  made  by  suppliers* 
corporate  system  designers*  and  standards  groups  concerning 
their  respective  efforts  to  address  data  exchange  problems. 
Various  offers  were  advanced  as  to  which  existing  specifications 
could  be  made  available  in  order  to  assist  in  the  development  of 
the  IGES  set  of  exchange  specifications. 


It  was  decided  to  use  the  Boeing  CAD/CAM  Integrated 
Information  Network  (CIIN)  standard  format  as  the  basis  on  which 
to  define  the  exchange  specifications.  This  was  done  because 
that  system  had  been  in  use  for  several  years  and  was  known  to 
work.  (As  a result*  the  IGES  structure  is  similar  to  that  of 
CIIN.  However*  IGES  is  not  purely  a CIIN  derivative.  Many  of 
the  features  presently  in  IGES  were  not  in  CIIN.  ) Information 
stemming  from  General  Electric's  work  on  a Neutral  Data  Base  was 
used  as  a source  of  advanced  concepts*  as  were  numerous  other 
formats  provided  to  the  Technical  Committee.  [References  3 and 
4 pertain  to  CIIN*  Reference  7 pertains  to  the  General  Electric 
Neutral  Data  Base.  3 


The  upcoming  effort  was  officially  dubbed  as  IGES*  and  the 

* Department  of  Defense  Manufac tur ing  Technology  Advisory 
Group 


!GES  ri/siSsstones 

September,  — DOD/MTAG  Workshop  Session 
1979  On  CAD/CAM  Interaction 

October  — Boeing  CHINS  System  Offered  As 

Basis  for  !GES 

• _ 

— Technical  Committee  Estab- 
lished 

— Work  Began  for  Jan.  1, 1930 
Publication  of  Specifications 
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November  — First  Input  Meeting; 

Suppliers,  Corporate 
Systems  Personnel 

December  — Second  Input  Meeting; 

Interested  Public 

January,  1280  — Publication  of 

Specifications 


February  — IGES  Committee  Structure 
Set  Up 

March  — Early  Thoughts  on  Testing, 

Benchmarking,  Demonstration 

May  — IGES  Adopted  by  ANSI  Subcom- 
mittee Y14.23  to  be  Part  of  Proposed 
American  National  Standard 

June  — Detailed  Technical  Design 

Meetings  Between  IGES  and  Par- 
ticipating Suppliers 
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IGES  Committee  Structure 
Bradford  Smith 
National  Bureau  of  Standards 
IGES  Chairman 
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The  Near-Term  IGES  Schedule 

1.  June  — Detailed  technical 
meetings  with  participating  sup- 
pliers concerning  entity  mappings. 

2.  September  — Tapes  containing 
IGES  descriptions  of  individual 
entities 


The  Longer-Term  IGES 
Schedule 

1.  Summer,  Fall,  1980— Suppliers 
continue  processor  implemen- 
tation work 

2.  Public  demonstration  of 
cross-translation  capability 
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Technical  Committee  was  formed  to  produce  the  speci 
IGE8  is  officially  a project  of  the  Air  Force 
Computer-Aided  Manufacturing  (ICAM)  Program.  It  ia  au 
funda  from  the  Air  Force*  Army*  Navy*  and  NASA* 
coordinated  through  the  Air  Force  ICAM  office.  (It 
emphasized  that  this  funding  has  gone  only  to  th 
Bureau  of  Standards  for  directing  and  coordinating 
work.  The  considerable  part ic ipation  by  Boeing  and 
Electric*  by  means  of  the  Technical  Committee*  was 
and  the  cost  was  b.orne  by  these  two  organi  zat  ions.  ) 


f ications. 
Integrated 
pported  by 
which  are 
should  be 
e National 
the  IGES 
by  General 
voluntary* 


Two  public  meetings  were  held  while  the  specifications  were 
being  drawn  up.  The  first*  on  November  20  in  Schenectady*  NY* 
was  for  suppliers  and  corporate  systems  personnel.  The  second* 
on  December  14  in  Washington*  was  for  the  interested  public.  In 
each  case*  opportunity  was  provided  for  reaction  to  what  existed 
at  that  time*  and  for  suggestion  and  criticism. 


The  IGES  specifications  were  published  in  January*  1980. 
In  May*  these  specifications  were  recommended  by  American 
National  Standards  Institute  (ANSI)  Subcommittee  Y14.  26  to  be 
part  of  a proposed  American  National  Standard.  (See  Section 
2.  4) 


Publication  of  the  IGES  Specifications  marked  the  end  of 
one  period  in  the  IGES  effort*  and  the  beginning  of  another. 
With  publication*  the  Technical  Committee  ceased  to  exist.  New 
committees  were  then  formed  whose  concerns  reflect  the  fact  that 
IGES  is  moving  toward  being  used. 

The  two  standing  IGES  committees  are  the  Steering  Committee 
and  the  Working  Committee.  The  Steering  Committee  is  a 
management  advisory  group.  Its  function  is  to  see  that  IGES  is 
promoted*  accepted*  and  used.  The  Working  Committee  is  the 
umbrella  technical  committee*  and  serves  as  the  focal  point  for 
technical  information  exchange.  It  has  several  subcommittees* 
each  of  which  performs  a specific  technical  task.  It  will  also 
be  concerned  with  carrying  out  the  directives  of  the  Steering 
Committee. 


At  its  first  meeting* 
Committee  requested  that  other 
Management  Briefing  Committee 
material  for  a scripted  slide 
be  of  interest  to  management. 


in  January*  1980*  the  Steering 
committees  be  formed.  One  is  the 
This  Committee  will  prepare 
presentation  on  IGES*  tailored  to 


The  Steering  Committee  also  requested 
Test*  Evaluate*  and  Support  Committee, 
committee  is  to  provide  cohesion  to 
determining  and  supplying  what  is  needed 
by  way  of  technical  support.  One  present 
formulation  of  test*  benchmark*  and  impl 
For  example*  in  initial  meetings  of  this 


the  formation  of  a 
The  function  of  this 
IGES  activities  by 
in  the  IGES  community 
concern  is  with  the 
ementation  procedures, 
committee*  discussion 
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involved  the  idea  of  a phased  implementation  for  IGES.  This  led 
to  a grouping  of  the  IGES  entities  into  two  exhaustive  subsets. 
One  subset  is  intended  to  form  a useful  set  of  entities  for 
mechanical  app 1 ications*  the  other  for  electrical  applications. 
(There  are  no  present  plans  for  identifying  rigid*  well-defined 
subsets  of  IGES*  with  the  thought  in  mind  that  a supplier  would 
implement  all  of  a certain  portion*  and  would  then  be  justified 

he  "meets"  that  portion.  There  is  instead 
the  marketplace  will  dictate  what  phased 
take  place.  Thus  the  two  subsets  mentioned 
more  in  the  spirit  of  attempting  to  establish 


in  proclaiming  that 
the  attitude  that 
implementation  will 
above  are  offered 


concensus  than  to  establish  any  type  of  official  designation.  > 


There  has  been  discussion  in  the  Test*  Evaluate*  and 
Support  Committee  to  the  effect  that  the  role  of  IGES  in  the 
benchmarking  procedure  will  be  to  make  various  "standard"  IGES 
tapes  available.  These  could  be  applications  oriented*  and 
possibly  graded  in  sophistication  in  some  manner.  Users  could 
then  make  use  of  these  tapes  as  they  chose*  to  assist  them  in 
their  decision  making  in  their  dealings  with  suppliers.  Several 
companies  have  volunteered  to  make  sample  parts  available  for 
use  in  these  tapes.  Also*  definitive  current  plans  call  for  the 
production  of  tapes  containing  IGES  descriptions  of  individual 
instances  of  some  of  the  basic  geometry  and  annotation  entities. 


The  Test*  Evaluate* 
in  IGES  providing  a 
suppliers*  and  between 
this  committee  will 
suppliers  in  order  to  discuss  entity  mapping  sc 
IGES.  The  Committee  will  then  consider  pairs  o 
and  anticipate  potential  cross-translat ion  prob 
schemes  put  forth*  and  will  provide  feedback  to 


and  Support  Committee 
forum  for  coordination 
suppliers  themselves, 
meet  individually  wi 


has  a direct  role 
between  users  and 
In  particular* 
th  participating 
hemes  to  and  from 
f schemes*  to  try 
lems  based  on  the 
the  suppliers. 


For  an  initial  public  demonstration  of  the  IGES  concept  and 
capab i 1 i t ies*  a sample  mechanical  part  has  been  agreed  upon  in 
order  that  suppliers  may  work  toward  being  able  to  accept  and 
produce  an  IGES  description  of  it.  (See  Appendix  B)  No  date  has 
been  fixed  for  a d emonstration. 


An  Extensions  and  Repairs  Committee  has  been  set  up  within 
the  Working  Committee.  This  committee  is  concerned  with  finding 
and  repairing  errors  and  ambiguities  in  the  specifications  docu- 
ment* and  with  clarifying  ports  of  the  manual  that  prove  diffi- 
cult to  understand.  For  extensions*  the  concern  is  not  with  the 
addition  of  new  entities  of  IGES.  Rather*  the  concern  is  with 
such  things  as  the  definition  of  new  standard  properties  and  as- 
soc iat  ivi  ties*  and  with  possible  macros.  In  fact*  concern  thus 
far  has  been  with  these  things  for  the  area  of  electrical  design. 

standard  assoc iot ivi ties  is  further  explained  in  the 
the  assoc iati vi ty  instance  entity.  ) 


(The  idea  of 
material  for 
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An  ANSI  Coordination  Committee  has  been  formed.  Future 
concerns  of  this  committee  are:  getting  the  IGES  specification 
into  the  required  ANSI  format#  and  coordinating  comments 
received  during  the  ANSI  review  processes. 

A Newsletter  Committee  and  a Coordination  Committee  have 
also  been  established.  Vol.  1#  No.  1#  of  the  IGES  Newsletter 
was  dated  May#  1980.  It  will  be  published  on  an  as-needed 
basis.  The  Coordination  Committee  is  a liason  committee  to 
other  interested  groups  and  to  professional  societies. 

A Software  Library  will  be  established  for  coordinating  the 
sharing  of  public  domain  software  generated  in  the  area 
surrounding  IGES. 


II.  IGES  Related  To  The  Technology  Of  Product  Definition 


Fundamental  changes  in  the  technology  of  product  definition 
have  brought  about  the  need  for  IGES.  These  changes  may  be  put 
in  perspective  by  concentrating  on  the  nature  of  the  models  used 
to  define  the  product  and  to  communicate  design  intent. 


2. 1 The  technology  of  product  definition 


Present  product  definition  methods  reflect  the 
this  technology  is  in  a transition  period.  The 
both  the  conventional  human-oriented  technology  and 
computer-oriented  technology  can  currently  be  found. 

The  traditional  model  for  product  definition 
human-oriented  engineering  drawings  and  associate 
Over  the  years#  the  art  of  creating  this  model  has  r 
attention.  The  discipline  of  drafting  methodology 
to  insure  that  design  intent  can  be  communicated  in 
manner  according  to  established  standards. 


fact  that 
influence  of 
of  the  newer 


consists  of 
d documents, 
eceived  much 
has  evolved 
an  orderly 


At  the  opposite  extreme  lies  a currently  intensive  research 
area  concerned  with  automated  production  via  "integrated 
systems".  In  particular#  much  attention  is  being  focused  on  the 
modeling  of  the  geometry  of  individual  components.  Here  the 
intention  is  that  the  solid  shape  of  a part  be  completely 
described#  by  means  of  a software  system  called  a geometric 
modeler#  in  a manner  capable  of  supporting  later  (automated) 
processing.  It  is  envisioned  that#  eventually#  larger  software 
systems  containing  geometric  modelers  within  them  will  have  the 
capability  to  give  precise#  complete  representations 
complicated  assemblies#  including  all  information  relevant 
and  manufacture  of 


the  design 


the  product#  and  also 


of 

to 

all 
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IGES 

Related  To 
The  Technology  Of 
Product  Definition 


The  Present  Technology 

Of 

Product  Definition, 
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Product  Definition  — 
Involves  Creation  Of  A Model  To 

1.  Define  the  Product  Itself  (Geometry) 
2.  Communicate  Design  Intent 


Traditional  Product  Definition 

1.  Human  Oriented 

2.  Engineering  Drawings  and 
Associated  Documents 

— Configuration  Data 

— Mathematical  Tables 

— Fabrication  Information 
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Future  Product  Definition  Technology 

1.  Complete  Computer  Description  Of 

— Product  Geometry  Sufficiently 

Sophisticated  to  Support  Automated 
Processing 

— Information  Necessary  to  Manufacture, 
Inspect,  Modify,  etc.  Product 

— Information  Necessary  to  Manage  These 
Processes 

2.  Computer  Description  Will  Accumulate  From 
Design  Onward 


Present  Product  Definition  Technology 

1.  Transition  State  Between 

— Human  Oriented  Traditional  Model 
— Computer  Oriented  Future  Model 

2.  Today's  Design-Drafting  Systems  Reflect  Both  Models 

— Computer  Generation  of  Human  Oriented 

Traditional  Model 

— Rudimentary  Geometry  Capability  for  Computer 
Oriented  Future  Model 

3d  Wire  Frame 

Limited  Planar,  Curved  Surface  Capability 
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information  necessary  to  effectively  manage  these  processes. 
Thus  for  a given  product*  a description  will  accumulate  from 
initial  design  onward*  and  will  provide  a consistent  source  of 
information  for  everyone  working  on  the  product. 

No  such  "integrated"  system  is  in  production  use  today. 
However*  integrated  systems  designed  to  address  various  portions 
of  the  entire  production  process  are  being  vigorously  pursued  in 
both  the  United  States  and  abroad.  * 

The  present  technology  for  product  definition  lies  between 
the  two  extremes  of  the  established  human-oriented  drafting 
methodology  and  the  research  in  automated  production.  On  the 
one  hand*  the  capabilities  of  the  interactive  graphics 
design-drafting  systems  being  marketed  today  reflect  the  fact 
that  these  systems  have  been  based  on  the  drafting  application. 
This  is  appropriate*  since  drawings  are  still  used  as  the 
primary  means  of  data  definition*  data  communication*  and  data 
storage.  Thus  the  predominant  current  effect  of  the  computer 
having  been  introduced  into  the  process  of  product  definition  is 
that  conventional  human-or iented  methods  have  been  automated  to 
some  degree. 

On  the  other  hand*  with  the  systems  being  marketed  today* 
three  dimensional  "wire  frame"  models  can  be  constructed*  and 
both  planar  and  curved  bounding  surfaces  are  available  to  be 
used  in  the  product  definition.  (In  fact*  the  systems  being 
marketed  today  are  character i zed  by  some  as  "edge-surface" 
systems.  ) It  is  true  that  at  present  the  emphasis  is  still  on 
the  preparation  of  an  engineering  drawing  from  the  three 
dimensional  model.  But  the  stage  is  now  set  for  the  shift  in 
attitudes  - and  practices  — that  will  result  from  the 
computer-oriented  model  eventually  being  considered  as  the 


* For  example*  the  "I"  in  both  the  IPAD  and  ICAM  acronyms 
represents  "Integrated".  (IPAD  is  Integrated  Programs  for 
Aerospace  Vehicle  Design*  and  ICAM  is  Integrated  Computer 
Aided  Manufacturing.  ) CAM-I  is  the  acronym  for  Computer 
Aided  Manuf ac turing-International*  Inc.  Uithin  CAM-I* 
standing  "projects"  exist*  each  having  specific  concerns 
within  the  production  process.  There  is*  among  others*  the 
Geometric  Modeling  Project*  and  the  Advanced  Numerical 
Control  Project.  A new  project*  the  CAM-I  Framework 
Project*  has  recently  been  formed*  and  will  act  as 
"Integrator"  for  the  various  projects.  Reference  1 provides 
information  relative  to  the  structure  and  concerns  of  CAM-I. 
References  5 and  6 give  overviews  of  ICAM  and  IPAD. 
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primary  definition  of  a part*  and  the  production  of 
human-oriented  drainings  as  an  application  feeding  off  the  model 
definition. 


2.  2 IGES  related  to  the  present  technology  of  product  definition 


IGES  has  been  tailored  to  accommodate  the  technology  of 
product  definition  as  it  exists  in  today's  interactive  graphics 
design-draf t ing  systems. 

First*  this  technology  is  accommodated  in  the  type  of 
entities  provided  in  IGES.  IGES  entities  allout  support  of  the 
traditional  drafting  application  - the  production  of  two 
dimensional  drawing  models.  In  addition  to  this*  IGES  is 
equipped  to  accommodate  the  eventual  shift  which  will  have  the 
computer-or iented  model  definition  as  primary  and  the 
human-oriented  drawing  as  a derivative  of  it.  Thus*  there  are 
IGES  geometry  entities  which  support  the  definition  of  three 
dimensional  wire  frame  models*  and  the  use  of  planar  and  curved 
bounding  surfaces.  IGES  can  further  support  the  distinction 
between  three  dimensional  computer  models  and  conventional  two 
dimensional  drawing  models  by  means  of  the  view  entity  and  the 
drawing  entity.  The  view  entity  allows  communication  of  a 
particular  "picture”  of  a given  three  dimensional  geometry 
configuration.  For  example*  parameters  pertaining  to  the  view 
point  and  to  clipping  may  be  communicated.  The  drawing  entity 
allows  communication  of  a two  dimensional  surface  onto  which 
views  have  been  projected  and  arranged  in  a selected  manner. 
Drafting  annotation  entities  may  also  be  included. 


IGES  also  contains  entities  to  allow  communication  of  data 
base  structure.  The  property  entity  enables  integer*  real*  or 
textual  data  to  be  related  to  a specific  entity.  Any  entity  in 
IGES  may  point  to  one  or  more  property  entities. 


The  assoc iativi ty  definition  entity 
definition  of  a logical  relationship  which 
entities*  without  the  specification  of  which 
used  in  any  given  "instance"  of  this 
associativity  instance  entity  specifies  this 


allows  for  the 
is  to  exist  between 
entities  are  to  be 
relationship.  The 
information. 


The  IGES  macro  definition  capability  provides  for  the 
definition  of  "new"  IGES  entities  in  terms  of  other  IGES 
entities  and  supplied  parameters.  For  example*  a variable  sized 
rectangle  could  be  defined  in  terms  of  the  variable  parameters 
of  length  and  width. 


The  associativity  definition  and  the  macro  definition 
entities  allow  extension  of  IGES  as  necessary  in  order  to  meet 
short  term  needs. 
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IGES 

Related  To  The  Present 
Product  Definition 
Technology 


IGES 

Accommodates  The  Technology 

Of 

Product  Definition 

As  It  Exists  In  Today's 
Interactive  Graphics 
Design-Drafting  Systems 


IGES  Does  This  1 hrough: 

1.  The  types  of  entities  it  has 

2.  The  particular  appli- 
cation-independent format 
it  uses 


The  SGES  Entitles 

1.  Can  Accommodate  Computer-Aided  Gener- 
ation of  Traditional  Engineering  Drawings 

2.  Can  Accommodate  Current  Capabilities  for 
Geometry  of  Computer-Oriented  Model 

— 3D  Wireframe 
— Planar,  Curved  Surfaces 

3.  Allow  Maintenance  of  Distinction  Between 
Human  Oriented  Model  and  Computer 
Oriented  Model 

— View  Entity 
— Annotation  Entity 
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The  IGES  Entities,  cont'd. 

4.  Allow  Maintenance  of  Database  Structure 
— Property  Entity 

— Associativity  Entity 

5.  Allow  Extension  as  Necessary  to  Meet 
Short-Term  Needs 

— Macro  Definition 
— Associativity  Definition 
— Text  Font  Definition 
— Line  Font  Definition 


The  IGES  Entity  Format  Has 
Been  Designed  To  Resemble 
Those  Found  !n  Today's 
Commercially  Available 
Interactive  Graphics  Design- 
Drafting  Systems 
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Entity  Format 

1.  In  Today's  Systems 

— Attribute  parameters  which  are  same  for 
every  entity 

— Definition  parameters  varying  from  entity 
to  entity 

2.  InIGES  • 

— A fixed  length  directory  entry  which  is 
same  for  aSi  ehtities 

— A variable  length  parameter  data  entry 
varying  from  entity  to  entity 
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A second  way  in  which  IGES  accommodates  the  technology  of 
product  definition  in  today's  systems  is  by  means  of  the 
application-independent  format  used  to  define  each  entity  in  a 
product  definition  file.  Entities  in  today's  systems  are 
determined  by  definition  parameters  varying  from  entity  to 
entity*  and  by  attribute  parameters  which  are  the  same  for  every 
entity.  Typical  examples*  respectively*  are  geometry  related 
parameters*  and  the  construction  layer  on  which  a given  entity 
is  defined. 


IGES  supports  this  format  in 
each  IGES  entity  has  two  parts: 
is  the  same  for  all  entities*  and 
can  vary  between  entities. 


a one-for-one  manner  in 
a directory  entry  format 
a parameter  data  entry 


that 

which 

which 


2.3  IGES  related  to  the  hierarchy  of  the 
definition 


geometry 
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day 


already 
too*  are 

in  their  three  dimensional 
this  section*  various 
for  solid  objects  are  touched,  upon*  and  some 
sought  regarding  their  relationship  one  to 


that  present 
at  the  level  of  "wire 
description  of  solid 
kinds  of  computer 


used 


> there  are  three  types 
to  represent  solid  objects. 


of  computer 
These  types 


type  is  the  edge  representation  model.  Here*  the 
of  stored  computer  definitions  of  the  edges  of 
the  object.  Depending  on  the  sophistication  of  a particular 
implementation*  such  information  as  which 
face*  or  which  edges  meet  at  a given  vertex  may 
contained  within  the  data  structure  of  the  model. 


The  advantages  of  this  type  of  model 
basically  a simple  model*  and*  provided  th< 
complicated*  it  can  be  used  profitably  in 
views  of  the  object.  The  fatal  disadvant< 
model  is  that  it  is  " inf ormationally  incomple 
that  more  than  one  solid  object  can  correspond  to  the  same  edge 
model.  (This  remains  true  even  when  only  polyhedral  objects  are 
being  considered!) 
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IGES 

Related  to  the  Hierarchy 
Of  the  Geometry 
Of 

Product  Definition  • 


Three  Current  Types  Of 
Computer  Representations 
For  Solid  Objects 

1.  Edge  Representation  Model 

2.  Boundary  Representation  Model 

3.  Volume  Representation  Model 
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Edge  Representation  Model 

1.  Conceptually  Simple 

2.  Natural  Extension  of  Drafting 
Technology 

3.  Does  Not  Necessarily  Delineate  a 
Single,  Unique  Object 


Boundary  Representation  Model 

1.  Involves  mathematically  specifying  all 
exterior  "faces"  of  the  object 

2.  The  totality  of  faces  defines  a unique 
physical  object 

3.  Implicitly  contains  the  Edge 
Representation  Model 

4.  Difficult  to  verify  integrity  of  model 
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Volume  Representation  Model 

1.  Involves  specifying  all  points  in  3D 
space  Occupied  by  the  object 

! 2.  Defines  a Unique  Physical  Object 

3.  Implicitly  contains  the  Boundary 
Representation  Model 


1.  SGES  is  oriented  to  the  edge 
representation  model,  but 
also  accommodates  limited 
surface  capability. 

2.  IGES  in  its  present  form 
does  not  accommodate 
either  boundary  representa- 
tions or  volume  representa- 
tions of  solid  objects. 
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Various  Geometric 
Modeling  Systems  For 
Solid  Objects 
Are  In  Development 
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bounding  envelope  for  the 
representation#  there  is  no  poss 
one  object  with  any  given  boun 
problem  that  was  mentioned  a 
disadvantage  of  the  edge  model  h 
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een  overcome. 

It  is  easg  to  see  that  there  is  inherently  more  information 
in  this  type  of  representation  than  there  is  in  the  edge 
representation.  In  fact#  for  a given  object#  the  required 
geometrical  information  needed  to  construct  an  edge 
representation  is  implicit  in  the  boundary  representation. 
However#  it  is  not  a trivial  task  to  verify  that  the  totality  of 
the  faces  does  indeed  form  exactly  a complete  bounding  envelope 
~ that  is#  with  no  part  of  the  object  left  unenclosed#  and  with 
no  superfluous  "dangling"  faces. 


The  third  type  of  computer  model  is  the  volume 
representation  model.  Here  the  intention  is  to  specify  all 
points  in  three  dimensional  space  that  are  occupied  by  the 
object.  There  is  sufficient  information  in  the  volume 
representation  model  to  be  able  to  derive  a boundary 
representat ion  model  from  it.  However#  while  this  is  very  easy 
to  accept  on  an  intuitive  basis#  neither  is  this  trivial  to 
actually  carry  out  in  an  automated  manner. 


Current  design-draf t ing  systems  deal  predominantly  with 
edge  repr esentat i ons#  although  as  mentioned  earlier#  certain 
bounding  surfaces  are  available  to  be  used  to  augment  the  edge 
representation.  Geometric  modelers  are  presently  under 
development  at  various  places  around  the  world#  based  on  both 
the  boundary  r epr esenta t i on  technique  and  the  volume 
representation  technique.  [Reference  2 describes  a recent  CAM-I 
sponsored  seminar  on  geometric  modeling.  In  addition  to  general 
discussion  on  geometric  modeling#  this  seminar  featured  reports 
on  the  status  and  capabilities  ol5  several  existing  geometric 
modelers.  1 The  prototype  modeler  PADL-1  out  of  the  Production 
Automation  Project  at  the  University  of  Rochester#  and  its 
successor  PADL-2#  now  under  development  there#  both  use  the 
volume  representation  to  au tomat i chi ly  generate  the  boundary 
representat i on  and  the  edge  representation.  [See  References  11 
and  123  Reference  9 provides  a technical  comparison  between  edge 
representation  models  and  volume  representation  models  of  a 
certain  type. 


IGES  in  its  present  form  does  not  accommodate  either 
boundary  representations  or  volume  Representations  of  solid 
objects.  This  is  considered  appropriate#  in  view  of  the  fact 
that  these  representations  are  not  in  common  use  today#  and  in* 
view  of  the  fact  that  the  underlying  motivation  for  IGES  was  to 
address  immediate  needs.  It  remains  to  be  seen  how  extensible 
IGES  proves  to  be  relative  to  this  current  research  area  — or# 
even  if  it  is  desired  for  it  to  be  extensible  in  this  manner. 
However#  it  is  certainly  reasonable  to  expect  that  CAD/CAM 
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systems  offered  by  suppliers  will  eventually  utilize  these  types 
of  representations  of  solid  objects. 

As  explained  below#  there  is  a current  standards  effort 
concerned  with  devising  a system  capable  of  accommodating  both 
boundary  and  volume  representations  of  solid  objects. 


2.  4 1GES  related  to  the  standards  technology  for  product 
definition 


Various  standards  currently  exist  which  pertain  to  the 
communication  of  product  definition  data  by  means  of 
conventional  engineering  drawings.  However#  in  spite  of  the 
fact  that  IGES  is  rapidly  becoming  a de  facto  national  standard# 
there  are  no  existing  national  standards  pertaining  exclusively 
to  the  communication  of  a complete  computer-oriented  product 
definition. 

The  ANSI  Subcommittee  Y14.  26  has  as  its  title  "Computer 
aided  preparation  of  product  definition  data".  This 
Subcommittee  has  been  in  existence  since  1970.  Task  Group  1 of 
this  Subcommittee  <Y14.26.  1)  has  been  concerned  with  computer 
representation  of  physical  object  shape  - that  is#  with  the 
geometry  portion  of  product  definition  data.  A system  for 
describing  geometry  has  been  devised  by  Y14.  26.  1.  The  intended 
use  of  this  system  is  to  facilitate  communication  of  object 
shape  descriptions  between  CA1>/CAM  programs#  and  between  data 
bases  of  intercommunicat ing  companies  — for  example#  between 
contractors  and  subcontractors.  The  system  has  been  designed  to 
accommodate  edge#  boundary#  and  volume  representations  of  solid 
objects.  The  feasibility  of  the  writing  of  pre-  and 
post-processors  for  the  system  proposed  by  Y14.  26.  1 has  yet  to 
be  pursued  by  Subcommittee  Y14. 26. 

Task  Group  11  (Y14.26.ll)  was  formed  in  1978#  and  is 

concerned  with  all  product  definition  data  other  than  geometry  - 
what  is  termed  "non-geometry"  data. 

A brief  history  of  the  recent  work  of  Subcommittee  Y14. 26 
is  appropriate.  At  the  August#  1978  meeting  of  this 
Subcommittee#  it  was  decided  to  begin  the  work  of  public 
coordination#  and  thus  to  issue  the  work  of  Y14.  26.  1 as  a 
Proposed  American  National  Standard#  entitled  "Digital 

Representation  of  Physical  Object  Shapes".  The  subsequent 
voting  at  the  Y14  level  produced  comments  on  the  Proposed 
Standard#  as  did  the  six  week  public  review  period  which  ended 
in  June#  1979. 

The  main  order  of  business  at  the  August#  1979  meeting  of 
Y14.  26  was  the  resolution  of  these  comments  (or#  at  least  to 
resolve  how  to  resolve  the  comments).  Resolution  of  all 
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!GE: 


Related  To 


The  Standards  Technology 

For 

Product  Definition 


1.  There  are  no  existing  national 
standards  pertaining  expressly  to 
a complete  computer-oriented 
product  definition. 

2.  5GES  does  pertain  expressly  to 
computer-oriented  product 
definition  data.  It  deals  with 
both  CAD  and  CAM.  It  is  rapidly 
becoming  a de  facto  standard. 


American  National  Standards  Institute  (ANSI) 

Y14  Committee— Engineering  Drawings 
And  Related  Documentation 


Y14,  Subcommittee  26  (Y14. 261— Computer  aided 
Preparation  of  Product  Definition 

Task  Group  Y14.26.1-  Digital  Representation  of 
Physical  Object  Shape 

Task  Group  Y14.2G.11  -Non-Geometry  Data 


May,  1980  Meeting  of  Y14.26 


Voted  to  Issue  IGES 
As  the  First  Three  Parts 
Of  a Five  Part 
Proposed  American 
National  Standard 


comment* 
that  Y14. 
meeting / 
re  issued 
American 
intention 


is  dictated  by  ANSI  procedure. 
26  uould  work  during  the  months 
and  that  the  revised  Propose 
during  the  summer  of  1980*  th 
National  Standard/  for  a per 
being  additional*  and  wider#  exp 


The  plan- adopted  was 
following  the  August 
d Standard  would  be 
is  time  as  a Draft 
iod  of  one  year  — the 
osuri. 


A meeting  was  convened  for  Subcommittee  Y14.  26  on  May  1#2# 
1980.  The  main  order  of  business  was  consideration  by  the 
Subcommittee  regarding  1GES  being  adopted  as  an  American 
National  Standard.  A motion  was  approved  concerning  a Proposed 
Standard  Y14.  26.  X#  entitled  Digital  Representation  for 
Communication  of  Product  Definition  Data.  (A  motion  was  also 
approved  to  the  effect  that  X not  be  equal  to  1.  The  exact 
number  of  this  Proposed  Standard  will  be  coordinated  with  ASME# 
the  Y14  Secretariat.  > 


Y14.  26.  X is  to 


be  composed  as  follows: 


Foreword 


Part 

1 

Data  Form  (a 

Part 

2 

Geometry  (as 

Part 

3 

Non-Geometry 

Part 

4 

Geometry  (as 

Part 

5 

Non— Geometry 

Further  pa 

lints  expressed 

, presented  in  IGES) 

presented  in  IGES) 

(as  presented  in  IGES) 
presented  in  Y14.  26.  1) 

(as  presented  in  yl4.  26.  1) 
n the  motion  were: 


1.  IGES  (Version  1)  be  forwarded  by  Y14  Subcommittee  26  as 

Parts  1#  2#  and  3 of  the  proposed  standard  to  the  Y14 

Standards  Committee  to  begin  the  review  and  approval 
process  as  an  American  National  Standard. 

2.  IGES  group  as  th®  proponent  be  responsible  for 

considering  comments  arising  from  submittal  of  the 
Foreward#  Farts  1#  2#  and  3 of  the  proposal  for 

approval  as  an  American  National  Standard. 


IGES  and  Y14.  26.  1 Task  cooperate 
Y14. 26. X Part  4 geometry  format. 


in  formulating  the 


4.  Y14.  26.  1 and  Y14.26.ll  Tasks  be  responsible  for 

considering  comments  arising  from  submittal  of  Parts  4 
and  5#  respectively#  of  the  supplementary  proposals  for 
approval  as  an  American  National  Standard. 


Item  3 refers  to  the  fact  that  the  IGES  assoc iativity 
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entity  is  to  be  used  to  express*  in  the  ICES  format*  the 
geometry  as  presented  by  Y14.  26.  1.  It  was  recommended  at  the 
meeting*  and  agreed  to  by  the  participants*  that*  in  the 
interest  of  achieving  a single  American  National  Standard  format 
for  communication  of  geometry  data*  the  Y14.  26.  1 geometry  could 
and  should  use  the  ICES  format  structure. 
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A Specification  ' 
For  The 
Exchange 
Of  . 

Product  Definition 

Data 
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The  Initial  Graphics  Exchange  Specification  (IGES)  has  been 
designed  to  accommodate  the  exchange  of  product  definition 
information  between  Computer-aided  Design  and  Computer-aided 
Manufacturing  (CAD/CAM)  systems. 
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Product  definition#  as  it  is  generated  in  today's 
commercially  available  interactive  graphics  design-drafting 
systems#  can  be  subdivided  into  three  categories:  geometry# 
annotation#  and  structure. 


The  category  of 
product  definition 
points#  lines#  arcs# 


geometry  consists  of  that 
which  describes  the  product  i 
ruled  or  parametric  surfaces# 


part 

of 

the 

self# 

such 

as 

etc. 

part 

of 

the 

and 

topol 

ogy 

The  category  of  annotation  consists  of  that 
definition  used  to  clarify  and  enhance  the  geometry 
of  the  product.  For  example#  when  product  information  is 
communicated  in  the  form  of  an  engineering  drawing#  annotation 
includes  dimensioning  and  tolerancing  information  such  as 
dimension  lines#  text#  true  positioning  symbols#  etc. 


The  structure  category  consists  of  the  various  logical 
relationships  that  exist  within  the  product  definition  file. 
Logical  relationships  may  exist  between  the  elements  of  the 
product  definition  itself#  as  when  specific  manufacturing 
instructions  are  associated  with  a specific  element  of  the 
geometry.  Or#  logical  relat ionsh ips  may  pertain  to  the  system 
involved  in  the  generation  of  the  product  definition#  as  when 
several  elements  in  the  definition  are  grouped  together  to  form 
an  entity  that  can  be  evaluated  and/or  manipulated  as  a single 
item. 


63 


IGES  Files 

Basic  Idea 

Product  Definition  Information 
Is  Communicated  As 
A File  Of  Entities 


64. 


An  entity  is  the  information  unit  in  an  I6ES  file. 

The  basic  idea  in  an  IGES  file  is  that  product  definition 
information  is  communicated  by  means  of  a list*  or  file*  or  IGES 
entities.  The  format  of  the  IGES  entities  is  application 
independent.  The  essence  of  the  IGES  effort*  as  far  as  the 
publishing  of  the  specifications  uias  concerned*  consisted  of 
determining  what  entities  were  to  be  included*  and  the  format 
for  each. 
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8GES  Entity  Categorie 


1.  Geometry  Entities 

2.  Annotation  Entities 

3.  Structure  Entities  • 


There  are  three  broad  categories  of  entities  in  IGES: 
geometry  entities*  annotation  entities#  and  structure  entities. 


' .1. 

■ 

. 

' 
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IGES  Entity  Structure 

Each  IGES  Entity 
Has  Two  Parts 

1.  A directory  entry 

2.  A parameter  data  entry 


68. 


Each  entity  in  IGES  has  two  parts.  The  first  part  consists 
of  a directory  entry*  the  second  part  a parameter  data  entry. 


The  form  of  the  directory  entry  is  fixed.  It  is 
for  all  entries.  The  parameter  data  entry  varies  from 
entity. 


Within  an  IGES 

file* 

al 

into 

one  section* 

and 

all 

into 

one  section. 

Within 

contiguous  records. 

1 directory  entries  are 
parameter  data  entries  are 
a section*  each  entry 


the  same 
entity  to 


gathered 

gathered 

occupies 
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IGES  File  Format 

80  Character 
Records 

Using  ASCII  Characters 
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An  IGES  file  is  written  on  80  column  records.  using  the 
ASCII  character  set.  The  HO  character  records  were  chosen  as  be- 
ing as  universal  medium  as  possible  for  transfer  of  information 
between  different  computing  systems.  Numbers  are  recorded  in 
character  form,  to  simplify  the  problems  of  differences  in  word 
length  when  going  from  machine  to  machine. 


Each  record  in  the  file  has  a unique  letter  in  column  73. 
which  identifies  the  section  to  which  it  belongs.  For  example, 
the  directory  entry  section  has  a D in  this  column.  A right- 
justified  sequence  number  is  used  in  columns  74  through  80  to  in- 
dicate the  position  of  a record  within  a section. 
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IGES  Data  Types 

1.  Integer  (Fixed-Point)  Constants 

2.  Floating-Point  Constants 

3.  String  Constants 

4.  Pointer  Constants 

5.  Language  Statement  Constants 

i 


There  are  five  data  type*  in  IGES:  integer  (fixed  point) 
constants*  floating  point  constants*  string*  pointer  constants 
and  language  statement  constants. 


Integer  constants  may  be  positive  or  negative  or  zero.  The 
number  of  bits  used  by  a particular  machine  for  integer 
representation  can  be  specified  within  an  IGES  file. 

Floating-point  constants  are  distinguished  by  the  presence 
of  a decimal  point.  IGES  permits  both  single  and  double  preci- 
sion floating  point  constants.  A single  precision  floating  point 
constant  may  be  expressed  with  or  without  an  exponent.  Double 
precision  constants  must  be  in  exponential  form. 

String  constants  in  IGES  use  the  Hollerith  form  as  found  in 
the  ANSI  specification  of  FORTRAN.  A string  constant  is 
preceded  by  an  unsigned  integer  (the  character  count  of  the 
string)  and  the  letter  "H".  Any  character  from  the  ASCII 
character  set  may  be  used.  There  is  no  limit  on  the  size  of  a 
string  constant.  In  particular*  string  constants  may  cross  card 
boundaries. 


A pointer  at  a particular  location  in  an  IGES  file  is  a 
device  used  to  indicate  that  additional  information  exists 
elsewhere  in  the  file.  For  example*  within  the  directory  entry 
for  each  IGES  entry*  there  is  a pointer  into  the  parameter-  data 
section  specifying  the  location  of  the  parameter  data  for  that 
entity. 


All  other  uses  of  pointers  deal  with  the  situation  in  which 
one  IGES  entity  is  referenced  by  another.  In  these  cases*  there 
is  a pointer  from  the  referencing  entity  to  the  directory  entry 
of  the  referenced  entity.  The  pointer  may  be  located  in  either 
the  directory  entry  section  or  the  parameter  data  section  of  the 
referencing  entity. 


For  example*  suppose  that  in  given  product  definition 
information*  the  four  sides  of  a rectangle  have  been  related*  in 
an  unordered  manner*  and  labeled  by  a name.  Then*  in  the 
corresponding  IGES  file#  this  association  - called  a group  - is 
recorded  by  means  of  an  IGES  entity  called  an  associativity 
instance.  Within  the  parameter  data  for  this  associativity 
instance  entity#  there  will  be  pointers  to  the  directory  entries 
of  each  of  the  four  straight  line  entities  of  the  rectangle.  In 
addition#  within  the  parameter  data  for  each  of  the  straight 
line  entities*  there  will  be  a back  pointer  to  the  associativity 
instance  entity*  to  indicate  that  the  particular  straight  line 
is  a member  of  the  group.  The  name  of  the  group  can  be 
accommodated  by  the  associativity  instance  entity. 


Pointers  are  implemented  using  the  sequence  numbers. 


A fifth  data  type* 
for  macro  definitions, 
ters  and  is  not  preceed' 
constant.  Its  length 
data  record  count  in  th 


the  language  statement  constant  is  used 
It  consists  simply  of  a string  of  charac- 
d by  the  "nH"  construction  of  the  string 
must  be  determined  through  the  parameter 
directory  entry  for  the  entity. 


73. 


Free  Format 


74. 


The  data  in  several  sections  of  an  I6ES  file  may  be  entered 
in  free  format.  The  free  format  feature  allows  the 
specification  of  parameters  in  a prescribed  order*  but  does  not 
specify  a location  on  the  record.  When  free  format  is  permitted 
the  following  rules  apply: 


1.  Blanks  are  ignored. 

2.  Commas  are  used  to  separate  parameters. 


3. 

A semicolon  is 
parameters. 

used 

to  terminate 

the 

list 

of 

4. 

When  two  commas 

appear 

adjacent  to 

each 

other 

(or 

separated  only  by  blanks)  the  pertinent  parameter  is 
not  specified  in  the  file  and  should  be  given  a default 
value. 

5.  If  a semicolon  appears  before  the  list  of  parameters  is 
complete*  all  remaining  parameters  should  be  given 
default  values. 

6.  Blanks  are  not  ignored  in  string  constants.  In 
addition*  the  comma  and  the  semicolon  are  treated  as 
characters  in  a string  constant*  and  do  not  have  the 
meaning  specified  in  <2)  through  (5)  above. 


75. 


IGES  Fife  Structure 

1.  Start  Section 

2.  Global  Section 

3.  Directory  Entry  Section 

4.  Parameter  Data  Section 

5.  Terminate  Section 
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Each  IGES  file  contains  five  subsections:  the  Start 
Section*  the  Global  Section*  the  Directory  Entry  Section*  the 
Parameter  Data  Section*  and  the  Terminate  Section.  The 
subsections  must  appear  in  this  order. 
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IGES  FILE  STRUCTURE 


78. 


TERMINATE  SECTION 


The  arrows  between  the  Directory  Entry  and  the  Parameter 
Data  Sections  illustrate  the  action  of  the  pointers. 


$ 


A Closer  Look 
At  The 

1GES  File  Subsections 
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START  SECTION 


THIS  SECTION  IS  A MAN  READABLE 


S0000001 


PROLOG  TO  AN  IGES  FILE.  IT  CAN  CONTAIN 


S0D00002 


AN  ARBITRARY  NUMBER  OF  RECORDS 


S000G003 


USING  ASCII  CHARACTERS  IN  COLUMNS  1-72  S0000020 
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The  Start  Section  of  a IGES  file  provides  a man-readable 
prologue  to  the  file. 

Each  Start  Section  record  has  an  "S"  in  column  73»  and  a se- 
quence number  in  columns  74  through  80.  The  information  in 
columns  1 through  72  does  not  have  to  be  formatted  in  any  special 
uay,  except  that  the  ASCII  character  set  must  be  used. 

There  must  be  at  least  one  Start  record. 
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GLOBAL  SECTION 
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83. 


IMTEGER  NUMBER  OF  BITS  IN  A DOUBLE  PRECISION 

MANTISSA 


The  Global  Section  contains  information  describing  the 
pre-processor*  and  information  needed  by  the  post-processor  in 
order  to  handle  an  1GES  file. 

Global  Section  records  have  a "G"  in  column  73.  The  parame- 
ters for  the  Global  Section  are  input  in  free  format. 
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DIRECTORY  ENTRY  (DE)  SECTION 


SEQ  # 

D 

10 

SEQ# 

D 

20 

STATUS 

#'S 

9 

ENTITY 

SUB- 

SCRIPT 

# 

19 

LABEL 

DISPLAY 

► 

8 

ENTITY 

LABEL 

18 

DEFINING 

MATRIX 

► 

7 

RESERVED 

^ . 

17 

VIEW 

► 

6 

RESERVED 

16 

LEVEL 

#.► 

5 

FORM 

NUMBER 

# 

15 

LINE  FONT 
PATTERN 

#,► 

4 

PARA- 

METER 

RECORD 

COUNT 

# 

14 

VERSION 

#.► 

3 

PEN 

NUMBER 

# 

13 

PARA- 

METER 

DATA 

► 

2 

LINE 

WEIGHT 

# 

12 

ENTITY 
TYPE  NO. 

# 

1 

✓ 

ENTITY 
TYPE  NO. 

# 

11 

H.OH003H  Izauooau 


NUMBER 

POINTER 

NUMBER  OR  POINTER  (POINTER  HAS  NEG  SIGN) 


The  Directory  Entry  Section  of  an  IGES  file  has  one  entry* 
consisting  of  two  records#  for  each  entity  in  the  IGES  file.  The 

two  records  contain  twenty  fields  of  eight  columns  each.  The 

meaning  attached  to  each  field  does  not  vary  between  entities. 

The  contents  of  the  directory  tend  to  be  that  data  common 
to  all  entities  in  the  file.  The  first  field  specifies  the  IGES 
entity  number.  The  second  field  is  a pointer  to  the  location 
within  the  Parameter  Data  Section  of  the  parameter  data  for  the 
entity.  Information  in  the  remaining  fields  is  referred  to  as 
attribute  data.  This  information  may  be  specified  by  a number 
value*  or  by  a pointer  to  the  directory  entry  of  another  IGES 
entity.  In  some  cases*  there  is  a choice. 

A typical  example  of  an  attribute  specified  by  a value  is 
in  field  twelve*  where  the  pen  number  value  specifies  which  pen 
a plotter  would  use  to  draw  an  image  of  the  entity.  A pointer 
would  be  used  in  field  five*  whenever  the  entity  is  to  be 
defined  on  more  than  one  working  level.  (Some  systems  allow 
entities  to  be  defined  on  as  many  levels  as  is  convenient.  ) In 
fields  involving  a choice#  a pointer  is  specified  by  the 
presence  of  a negative  sign. 
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The  Parameter  Data  Section  of  an  IGES  file  contains,  the 
parameter  data  entries  of  the  entities  in  the  IGES  file. 
Parameter  data  varies  from  entity  to  entity. 

Parameter  data  is  entered  in  free  format#  with  the  first 
field  always  containing  the  entity  type  number.  Thus#  the 
entity  type  number  and  a comma  always  precede  the  first 
parameter  for  each  entity.  The  free  field  part  of  each 
parameter  record  ends  in  column  64.  Columns  65  through  72  on 
each  parameter  record  contain  pointer  to  the  sequence  number  of 
the  first  record  in  the  directory  entry  for  the  entity  to  which 
the  parameter  data  belongs.  Column  73  contains  a "P".  As  usual# 
sequence  numbers  are  located  in  columns  74  through  80. 

With  the  exception  of  text  strings#  parameter  data  values 
are  restricted  from  crossing  record  boundaries.  For  each  entry# 
comments  can  be  added  following  the  parameter  data#  giving  the 
possibility  of  furnishing  human  readable  information  when  neces- 
sary. 
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< 


90 


Each  IGES  file  has  one  record  in  the  Terminate  Section, 
vided  into  ten  fields  of  eight  columns  each.  This  records 
be  the  last  record  in  the  file.  It  has  a "T"  in  column  73, 
GOOOOOl  in  columns  74  through  80. 

The  first  four  fields  on  the  terminate  record  give 
number  of  records  in  each  of  the  four  previous  sections. 


d i - 
must 
and 


the 
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A Closer  Look 


ES  Err 


A 


IGES  GEOMETRY  ENTITIES 

ENTITY  TYPE  ENTITY  TYPE  NUMBER 

CIRCULAR  ARC  ENTITY 

100 

COMPOSITE  CURVE  ENTITY 

102 

CONIC  ARC  ENTITY 

104 

COPIOUS  DATA  ENTITY 

ioa 

PLANE  ENTITY 

108 

LINE  ENTITY 

110 

PARAMETRIC  SPLINE 

112 

PARAMETRIC  SPLINE  SURFACE  ENTITY 

114 

POINT  ENTITY 

116 

RULED  SURFACE  ENTITY 

118 

SURFACE  OF  REVOLUTION  ENTITY 

120 

TABULATED  CYLINDER  ENTITY 

122 

TRANSFORMATION  MATRIX  ENTITY 

124 

93. 


The  IGES  Geometry  entities.  Most  of  the  geometry  entities 
are  defined  directly  in  three  dimensional  X#  Y#  2 model  space. 
(That  is#  the  coordinate  system  in  which  the  model  is  defined. ) 
The  circular  arc  entity  and  the  conic  arc  entity  are  exceptions. 


I 


94. 


Example: 

The 

Circular  Arc 


95. 


c 
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Circular  arcs  can  be  defined  with  the  I6ES  circular  arc  en- 
tity. Coordinate  information  for  arc  endpoints  A and  B is  part 
of  the  parameter  data.  By  considering  an  arc  to  be  drawn  coun- 
terclockwise from  the  point  listed  first  to  the  point  listed 
second/  a given  arc  can  be  distinguished  from  its  complementary 
arc  (which  has  the  same  endpoints). 
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CIRCULAR  ARC  ENTITY 


DIRECTORY  ENTRY  FIELDS 

ENTITY  NUMBER 

100 

STATUS 

# 

PARAMETER  DATA 

► 

LINE  WEIGHT 

# 

VERSION 

#,► 

PEN  NUMBER 

# 

LINE  FONT 

#.► 

PARAMETER  CARD  CT. 

# 

LEVEL 

#.► 

FORM  NUMBER 

# 

VIEW 

ENTITY  LABEL 

MATRIX 

ENTITY  LABEL  SUB 

# 

LABEL 

SEQUENCE 

PARAMETER  DATA 


&RAMETER 

VALUE 

FORMAT 

1 

Z 

FLOATING  POINT 

2 

X 

FLOATING  POINT 

3 

Y 

FLOATING  POINT 

4 

X 

FLOATING  POINT 

5 - 

Y 

FLOATING  POINT 

6 

X 

FLOATING  POINT 

7 

Y 

FLOATING  POINT 

8 

N 

INTEGER 

9 

DE 

POINTER 

8 + N 

DE 

POINTER 

9 + N 

M 

INTEGER 

10  + N 

DE 

POINTER 

• 

• 

• 

• 

• 

• 

• 

• 

• 

9 + N + M 

DE 

POINTER 

COMMENT 


CENTER  DISPLACEMENT 
FROM  XT-YT  PLANE 
CIRCLE  CENTER  ABSCISSA 
CIRCLE  CENTER  ORDINATE 
END  POINT  ONE  ABSCISSA 
END  POINT  ONE  ORDINATE 
END  POINT  TWO  ABSCISSA 
END  POINT  TWO  ORDINATE 
NUMBER  OF  BACK  POINTERS 
(TO  ASSOCIATIVITY  ENTITIES) 
/TEXT  POINTERS  (TO  GENERAL 
NOTE  ENTITIES) 

POINTERS  TO  ASSOCIATIVITIES 
OR  GENERAL  NOTES  . 

r 

NUMBER  OF 

PROPERTIES 

POINTERS  TO  PROPERTIES 


In  IGES*  an  arc  of  a circle  is  specified  by  giving  planar 
coordinates  for  the  tuio  endpoints  of  the  arc*  and  the 
coordinates  of  the  center  of  the  parent  circle  for  the  arc.  (See 
parameters  2 through  7 in  the  parameter  data. ) 

The  definition  plane  for  the  arc  is  termed  the  XT*YT  plane* 
and  is  different  from  model  space.  The  arc  can  be  considered  to 
be  rigidly  displaced  in  a direction  perpendicular  to  the  XT*YT 
plane  (that  is*  in  the  ZT  direction)*  as  parameter  1 in  the 
parameter  data  indicates. 

The  remaining  parameters  in  this  entity  have  to  do  with 
possible  related  entities.  For  example*  if  an  arc  is  one  of  the 
entities  in  a group*  then  the  associativity  instance  entity 
specifying  the  various  group  elements  could  be  pointed  to  by  the 
circular  arc  entity  as  being  an  associated  entity. 

The  arc  in  the  XT*YT  plane  is  situated  into  model  space  by 
use  of  the  IGES  transformation  matrix  entity.  This  entity 
consists  of  a rotation  matrix  and  a translation  vector.  Field  7 
in  the  directory  entry  for  the  circle  contains  a pointer  to  the 
matrix  entity. 


o 
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IGES  ANNOTATION  ENTITIES 

ENTITY  TYPE  ENTITY  TYPE  NUMBER 


ANGULAR  DIMENSION 

202 

CENTERLINE 

106 

DIAMETER  DIMENSION 

206 

FLAG  NOTE 

208 

GENERAL  LABEL 

210 

GENERAL  NOTE 

212 

LEADER  (ARROW) 

214 

LINEAR  DIMENSION 

216 

ORDINATE  DIMENSION 

218 

POINT  DIMENSION 

220 

RADIUS  DIMENSION 

222 

SECTION 

106 

WITNESS  LINE 

106 

100. 


The  IGES  Annotation  entities.  Annotation  entities  are 
part  of  the  physical  part  description  itself.  Rather# 
serve  primarily  to  enhance  the  physical  description  of  the 
such  as  in  the  case  of  a linear  or  an  angular  dimension. 


not 

these 

part# 
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102. 


i— 1.5772 

T 

> 

1.1160 

-J  1.5772  L- 

1 

EXAMPLE  1 

EXAMPLE  2 

• 

EXAMPLE  3 

EXAMPLES  OF  LINEAR  DIM 

ENSIGNS 

103. 


A linear  dimension  entity  consists  of  a general  note*  tuio 
leaders*  and  zero  to  two  witness  lines.  The  IGES  general  note 
entity  is  used  for  all  text  in  an  IGES  file.  Here*  this 
consists  of  the  numerical  values  shown.  The  leaders  are  the 
portions  of  the  entity  containing  the  arrowheads.  The  witness 
lines  are  used  as  needed. 


0 


104 


LINEAR  DIMENSION 
DIRECTORY  ENTRY  FIELDS 

ENTITY  NUMBER 

216 

STATUS  # 

PARAMETER  DATA 

VERSION 

LINE  FONT 

LEVEL 

VIEW 

MATRIX 

LABEL 

► LINE  WEIGHT  # 

#,  ► PEN  NUMBER  # 

#,►  PARAMETER  CARD  CT.  # 

#,►  FORM  NUMBER  # 

► ENTITY  LABEL  ; 

► ENTITY  LABEL  SUB  # 

► SEQUENCE  1 

PARAMETER  DATA 

PARAMETER 

VALUE 

FORMAT 

COMMENT 

1 

DENOTE 

INTEGER 

POINTER  TO. GENERAL  NOTE  DE 

2 

DEARRW1 

INTEGER 

POINTER  TO  FIRST  LEADER  DE 

3 

DEARRW2 

INTEGER 

POINTER  TO  SECOND  LEADER  DE 

4 

DEWIT1 

POINTER 

POINTER  TO  WITNESS  LINE  DE, 

5 

DEWIT2 

POINTER 

0 IF  NOT  DEFINED 

6 

N 

INTEGER 

NUMBERS  OF  BACK  POINTERS 
(TO  ASSOCIATIVITY  ENTITIES)/TEXT 
POINTERS  (TO  GENERAL  NOTE 
ENTITIES) 

7 

DE 

POINTER 

POINTERS  TO  ASSOCIATIVITIES 

• 

• 

• 

OR  GENERAL  NOTES 

...  - - ! 

! 

• 

■ 

6|+ N 

■ 

DE 

• 

m 

POINTER 

i 

! 

■ j 

7|+N 

M 

INTEGER 

NUMBER  OF  PROPERTIES 

8 + N 

DE 

POINTER) 

POINTERS  TO  PROPERTIES 

t 

• 

7r»-  N + M 

» 

• 

DE 

■ 

■ 

POINTER 
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A portion  of  the  parameter  data  for  the  linear  dimension 
entity  indicates  that  this  entity  really  consists  of  a set  of 
pointers  to  other  annotation  entities.  Thus*  the  witness  line 
in  this  entity  is  an  example  of  a subordinate  entity.  An  IGES 
entity  is  considered  to  be  a subordinate  entity  as  it  was 
created  purely  as  a subpart  of  another  entity  - that  is*  would 
not  be  used  independently.  A flag  in  the  directory  entry  is 
used  to  indicate  if  a given  entity  is  a subordinate  entity. 
(Entities  formed  into  a group  by  means  of  an  assoc iativi ty 
instance  entity  are  not  subordinate  entities.  ) 

For  a linear  dimension  entity*  an  associated  entity  could 
conceivably  be  the  geometry  entity  to  which  the  dimension  value 
refers. 
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The  IGES 
View  and  Drawing 
Structure  Entities 


107. 


Two  other  IGES  structure  entities  are  the  view  entity  and 
the  drawing  entity.  These  two  entities  reflect  an  attempt  to 


maintain  within  IGES  the 
dimensional  description  of 
representation  of  the  model* 
engineering  drawing.  The 
model  and  two  dimensional 


distinction  between  the  three 
a model*  and  a two  dimensional 
as*  for  example*  in  the  form  of  an 
intent  is  to  allow  the  two  ideas  of 
representation  to  be  dealt  with 
separately*  while  maintaining  a single  model  description  within 
the  database.  This  contrasts  with  the  situation  where  either 
the  model  description  itself  must  be  changed  in  order  to  get  a 
two  dimensional  representati on  such  as  a draftsman  would 

produce*  or  else  a copy  of  the  model  description  is  changed* 
thus  admitting  to  potential  compatibility  problems  when  updates 
are  made. 
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The  concept  of  what  type  of  information  the  view' entity  and 
the  drawing  entity  can  accommodate  is  illustrated  in  these  two 
pictures.  A portion  of  the  model  is  selected  using  a view 
cube. (In  two  dimensions#  the  term  "view  window"  might  possibly 
be  used  instead.  View  cube  is  a generalization  of  this  idea  to 
three  dimensions.  ) The  view  cube  is  used  to  identify  the  portion 
of  the  model  that  is  of  interest.  (For  example#  a portion  might 
be  selected  and  scaled  in  order  to  "blow  up"  a certain  detail.  ) 
Portions  of  the  model  outside  the  view  cube  are  "clipped"#  or 
removed.  Information  within  the  view  entity  is  then  used  to 
rotate  as  necessary  the  portion  of  the  model  within  the  view 
cube#  in  order  to  present  the  selected  geometry  on  the  two 
dimensional  drawing  in  the  desired  orientation, 
projection  onto  the  two-dimensional  drawing  is  made# 
control  is  allowed  over  entity  attributes  within  each 
example#  it  can  be  arranged  that  a line  be  dashed 
and  be  solid  in  another. 


As  the 
additional 
view.  For 
in  one  view 


The  drawing  entity  gives  the  capability  of  collecting  the 
results  of  view  operations  and  arranging  them  in  two  dimensional 
space  in  a manner  similar  to  conventional  drafting  practices. 
While  it  is  not  essential  to  do  so  in  the  use  of  IGES#  the 
drawing  entity  also  provides  a convenient  place  to  collect  the 
drafting  annotation  entities  which  aid  in  the  description  of  the 
model.  The  drafting  annotation  entities  are  essentially  two 
dimensional  objects.  By  confining  these  entities  to  the  two 
dimensional  representation  via  the  drawing  entity#  rather  than 


attaching  them  to  the  model  itself# 
form#  while  the  drawing  entity 
additional  descriptive  information. 


the  model  is 
is  used  to 


kept  in 
collect 


pure 

this 
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IGES  Structure  Entities 


1.  Associativity  Definition 

2.  Associativity  Instance 

3.  Annotation 

4.  Line  Font  Definition 

"T ‘ ■— ■■■  ■ ■ 

5.  MACRO  Definition 

6.  MACRO  instance.; 


7.  Property 

8.  Subfigure  Definition 

9.  Subfigure  Instance 

#/ 

10.  Text  Font  Definition, 

11.  View 
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The  purpose  of  the  IGES  structure  entities  is  to 
communicate  logical  relationships  between  IGES  entities.  The 
intent  is  to  be  able  to  faithfully  accommodate  the  structure 
within  an  originating  product  definition  file. 

The  assoc iativity  definition  and  the  subfigure  definition 
entities  have  been  mentioned  elsewhere. 


The  macro  capability  provides  for  the  definition  of  a "new" 
entity  in  terms  of  other  IGES  entities.  The  "new"  entity  schema 
is  provided  for  by  a macro  definition#  written  using  the  macro 
entity.  The  statements  permissable  are  the  assignment 
statement (LET)#  the  entity  definition  statement (SET)#  the  REPEAT 
statement#  causing  a group  of  statements  to  be  repeated  a 
specified  number  of  times#  the  CONTINUE  statement#  which 
terminates  the  REPEAT  group#  and  the  HREF  statement#  used  to 
refer  to  other  macros  from  inside  a macro  definition. 


The  text  font  definition  entity  is  used  to  define 
characters  and  character  fonts  not  provided  in  the  font 
definitions  of  IGES.  (In  the  IGES  General  Note  entity#  font 
character ist ics  are  identified  by  an  integer  between  0 and  6. 
These  integers  are  determined  on  a system  dependent  basis.  > The 
text  font  entity  pairs  an  ASCII  value  with  a subfigure.  The 
subfigure  contains  the  geometric  components  necessary  to  draw 
the  character. 


The  line  font  definition  entity  is  used  to  generate  line 
fonts  with  repeating  patterns.  Repeating,  patterns  are  specified 
by  on  or  off  line  segments.  Up  to  16  segments  can  be  used  in 
the  basic  repeating  pattern.  A repeating  subfigure  pattern  can 
also  be  accommodated  by  this  entity. 
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Subfiqure  Instance  Entil 
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A subfigure  is  exactly  like  a complete  part  description* 
except  that  it  is  intended  to  be  used  uiithin  the  description  of 
some  other  part.  Thus  an  "instance"  of  a subfigure  may  occur 
only  once  in  a part  design*  or  it  may  occur  many  times. 
Subfigures  may  be  nested*  thus  providing  a hierarchical 
capability. 


There  is  an  IGES  entity  dealing  with  the  definition  of  a 
subfigure*  and  also  an  IGES  entity  used  with  each  occurrence  of 
the  subfigure.  The  subfigure  definition  entity  specifies 
pointers  to  specific  entities  or  to  other  subfigures.  The 
subfigure  instance  entity  refers  back  to  the  definition*  and 
also  contains  information  pertinent  to  the  location  and  the 
scale  factor  for  a particular  occurrence. 


As  an  example 


occurrences 

of  a 

in  a 

part  design. 

the 

screw* 

and 

the 

design. 

of  the  use  of  a subfigure*  consider  the 
ex-head  screw  in  a number  of  different  places 
A subfigure  entity  could  be  used  to  represent 
subfigure  instance  for  each  occurrence  within 
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SUBFIGURE  DEFINITION  & INSTANCE 
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Property  Entity 
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The  property  entity  is  meant  to  contain  any  type  of  data 
(integer*  real*  or  text)  which  is  necessary  to  enhance  the 
description  of  a particular  entity.  For  example*  on  a printed 
wiring  board*  the  width  of  a line  which  is  part  of  a conductive 
path  could  be  specified  as  a property  value. 

Any  entity  in  IGE5  may  point  to  one  or  more  property 
entities.  Properties  are  referred  to  by  the  "associated 
properties"  pointers  in  the  parameter  data  of  the  IGES  entities. 

In  particular*  a property  entity  may  point  to  other 
property  entities*  thus  allowing  the  construction  of  networks. 
Networks  are  useful  for  maintaining  information  such  as  signal 
strings*  dimension  dependencies*  etc. 
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Associativity  Definition 
And 

Associativity  instance  Entities 
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The  IGES  assoc iat ivi ty  entity  is  like  the  subfigure  entity 
in  that  there  is  an  associativity  definition  entity  and  an 
associativity  instance  entity.  The  assoc iativi ty  instance 
entity  is  used  each  time  the  defined  associativity  relation 
occurs. 

However#  the  associativity  definition  entity  is  quite 
general.  It  specifies  the  structure  of  a logical  relationship 
rather  than  specific  entities  which  are  to  take  part  in  the 
relationship.  The  logical  relationship  may  entail  one  or  more 
independently  defined  "classes"#  each  of  which  may  have  one  or 
more  entries.  A class  may  be  ordered  or  unordered.  The 
assoc iativity  instance  defines#  for  each  occurrence  of  the 
assoc iativi ty  relation#  the  number  of  entries  in  each  class#  and 
the  necessary  data  for  each  entry. 

A group  is  perhaps  the  simplest  example  of  an 
associativity.  For  this#  there  would  be  one  class#  which  would 
be  unordered  (by  definition).  In  a given  instance#  each  entity 
to  appear  in  the  group  could  be  specified  by  a pointer. 
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ASSOCIATIVITY 
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ASSOCIATIVITY  DEFINITION 


12:1. 


ASSOCIATIVITY  INSTANCE 
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ASSOCIATIVITY  INSTANCE  AND  RELATED  ENTITIES 


An  example  of  an  associativity  instance  for  a group. 


This  associativity  instance  entity  specifies*  by  means  of 
the  parameter  Nl#  that  three  entries  are  to  be  involved  in  this 
particular  instance.  The  pointer  for  each  entry  identifies  the 
participating  entity. 


The  form  number  parameter  is 
assoc iativity  instance  entity 
associativity  definition  entity, 
can  be  accommodated. 


the  mechanism  by  which  the 
identifies  the  corresponding 
Form  numbers  from  1 to  9999 


If  the  form  number  is 
associativity  definition  will 
If  the  form  number  is  between 
definition  is  considered  to  be 
included  within  the  16ES  file. 


5001  and  9999#  then  the 
included  within  the  IGES  file, 
and  5000#  the  assoc iativi ty 
a "standard"  one#  and  need  not  be 


between 
be 
1 


Form  number  1 is  the  form  number  for  a group.  Thus#  the 
definition  is  known  to  specify  one  class*  unordered#  one  data 
item  for  each  entry  in  the  class*  which  will  be  a pointer.  The 
definition  also  specifies  that  each  entity  participating  in  a 
group  instance  will  contain  a back  pointer  to  the  parent 
associativity  instance  entity. 
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IGES  ENTITY  STRUCTURE 


!27. 


Q.  £• 


The  IGES  entity  structure.  A line  between  two  boxes  means 
that  the  information  in  both  boxes  is  within  the  same  set  of 
records.  A line  with  an  arrow  means  that  information  is  located 
elsewhere#  and  that  a pointer  is  used  to  locate  it.  Thus# 
ttributes  are  part  of  the  directory  entry  (DE).  The  entity 
efinition  box  is  used  in  those  cases  where  it  is  necessary  to 
either  change  an  existing  entity  definition  or  add  a new  entity 
definition. 
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